Change the desugaring of `assert!` for better error output #122661

estebank · 2024-03-17T21:19:33Z

In the desugaring of assert!, we now expand to a match expression instead of if !cond {..}.

The span of incorrect conditions will point only at the expression, and not the whole assert! invocation.

error[E0308]: mismatched types
  --> $DIR/issue-14091.rs:2:13
   |
LL |     assert!(1,1);
   |             ^ expected `bool`, found integer

We no longer mention the expression needing to implement the Not trait.

error[E0308]: mismatched types
  --> $DIR/issue-14091-2.rs:15:13
   |
LL |     assert!(x, x);
   |             ^ expected `bool`, found `BytePos`

Now assert!(val) desugars to:

match val {
    true => {},
    _ => $crate::panic::panic_2021!(),
}

Fix #122159.

rustbot · 2024-03-17T21:19:41Z

r? @pnkfelix

rustbot has assigned @pnkfelix.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

rustbot · 2024-03-17T21:19:43Z

rust-analyzer is developed in its own repository. If possible, consider making this change to rust-lang/rust-analyzer instead.

cc @rust-lang/rust-analyzer

The Miri subtree was changed

cc @rust-lang/miri

estebank · 2024-03-17T21:20:59Z

src/tools/miri/tests/pass/binops.rs

-    assert!((() <= ()));
-    assert!((!(() > ())));
-    assert!((() >= ()));
+    assert!(!(() != ()));


All of these are because now the unnecessary parentheses lint (correctly) triggers on assert!((expr)).

estebank · 2024-03-17T21:22:05Z

tests/ui/issues/issue-14091-2.stderr

-error[E0600]: cannot apply unary operator `!` to type `BytePos`
-  --> $DIR/issue-14091-2.rs:15:5
+error[E0308]: mismatched types
+  --> $DIR/issue-14091-2.rs:15:13
   |
 LL |     assert!(x, x);
-   |     ^^^^^^^^^^^^^ cannot apply unary operator `!`
-   |
-note: an implementation of `Not` might be missing for `BytePos`
-  --> $DIR/issue-14091-2.rs:6:1
-   |
-LL | pub struct BytePos(pub u32);
-   | ^^^^^^^^^^^^^^^^^^ must implement `Not`
-note: the trait `Not` must be implemented
-  --> $SRC_DIR/core/src/ops/bit.rs:LL:COL
-   = note: this error originates in the macro `assert` (in Nightly builds, run with -Z macro-backtrace for more info)


This is the best example of how this is an improvement.

estebank · 2024-03-17T22:41:11Z

Sigh, clippy shows at least one test where a suggestion causes there to be a condition that isn't a bool but rather a type where Not returns a bool. We can easily continue supporting that by making the desugaring !!cond, but would rather not do that. This happens when it suggest changing assert_eq!(non_bool, true), ending up as assert!(non_bool), which doesn't work with this change .

pnkfelix · 2024-03-18T15:18:59Z

Isn't this technically a breaking change for e.g. (playground):

struct Booly(i32);

impl std::ops::Not for Booly {
    type Output = bool;
    fn not(self) -> Self::Output {
        self.0 == 0
    }
}

fn main() {
    assert!(Booly(1), "booly booly!")
}

pnkfelix · 2024-03-18T15:25:11Z

At the very least, we might need to tie such a change to an edition.

I am not certain whether this decision would be a T-lang matter or a T-libs-api one. I'll nominate for T-lang for now.

(Namely: The question is whether we can start enforcing a rule that the first expression to assert! must be of bool type, which is how the macro is documented, but its current behavior is a little bit more general, as demonstrated in my prior comment)

@rustbot label +I-lang-nominated

src/tools/rust-analyzer/crates/parser/test_data/parser/ok/0035_weird_exprs.rs

estebank · 2024-03-18T15:33:43Z

@pnkfelix we can keep the current (undocumented) behavior by making the desugaring be

{
    let x: bool = !!condition;
    x
}

instead of what this PR does:

{
    let x: bool = condition;
    x
}

I believe that would still cause errors to complain about Not not being implemented, instead of the more straightforward type error, albeit with a better span. I don't particularly like the idea of keeping the current emergent behavior if there aren't people exploiting it in crates.io.

Edit: an option would be to have an internal marker trait:

use std::ops::Not;
trait CanAssert {}
impl<T: Not<Output = bool>> CanAssert for T {}

fn main() {
    let _ = Box::new(true) as Box<dyn CanAssert>;
    let _ = Box::new(42) as Box<dyn CanAssert>;
}

error[E0271]: type mismatch resolving `<i32 as Not>::Output == bool`
 --> src/main.rs:7:13
  |
7 |     let _ = Box::new(42) as Box<dyn CanAssert>;
  |             ^^^^^^^^^^^^ expected `bool`, found `i32`
  |
note: required for `i32` to implement `CanAssert`
 --> src/main.rs:3:29
  |
3 | impl<T: Not<Output = bool>> CanAssert for T {}
  |             -------------   ^^^^^^^^^     ^
  |             |
  |             unsatisfied trait bound introduced here
  = note: required for the cast from `Box<i32>` to `Box<dyn CanAssert>`

pnkfelix · 2024-03-18T17:00:27Z

@estebank what about making the expansion edition-dependent? Is there precedent for that?

Then, editions >= 2024 would expand to what you have proposed in the code of this PR, and editions < 2024 could expand to the !!condition variant form that you have discussed in the comments?

pnkfelix · 2024-03-18T17:53:23Z

what about making the expansion edition-dependent? Is there precedent for that?

(to answer my own question, panic! is one obvious precedent here. So it seems like making it edition-dependent would be one acceptable path; no opinion yet as to which is best...)

rustbot · 2024-03-19T00:05:12Z

Some changes occurred in coverage tests.

cc @Zalathar

estebank · 2024-03-19T00:05:14Z

I tried the marker trait approach for <=2021, and it kind of worked, but the diagnostics were actually worse than just doing { let x: bool = !!$expr; x }, which accounts for pretty much everything we currently support, but with better spans and better errors (if typeof($expr) implements <Not<Output = NotBool>, we now produce an appropriate E0308 type error).

compiler-errors · 2024-03-19T16:40:43Z

Since I don't think it's been acknowledged above, for the record, this breaks the following code:

fn hello(x: &bool) {
  assert!(x);
}

Because &bool: Not<Output = bool>.

estebank · 2024-03-19T17:27:56Z

@compiler-errors that is indeed the case for 2024 onwards, not for previous editions.

pnkfelix · 2024-03-20T14:45:31Z

@compiler-errors that is indeed the case for 2024 onwards, not for previous editions.

I think the critical point is whether an edition-dependent expansion is worth breaking that case (of assert!(x) where x: &bool), or if we should do a non-breaking non-edition-dependent expansion using the let x: bool = !!$expr trick across the board...

Update: I don't know whether it is worth going through this exercise explicitly, but there is a design space here. E.g. one set of options is:

(stable Rust behavior): in all editions, support arbitrary impl Not<Output=bool> for first parameter to assert!;
in edition >= 2024, support just Deref<Target=bool> for first parameter to assert! (e.g. by expanding to let x: &bool = &$expr;), or
(this PR): in edition >= 2024, support just bool for first parameter to assert!.

(And then there's variations thereof about how to handle editions < 2024, but that's a separate debate IMO.)

pnkfelix · 2024-03-22T16:12:22Z

(this is waiting for a decision from T-lang and/or T-libs regarding what interface we want to commit to for assert!)

@rustbot label: +S-waiting-on-team -S-waiting-on-review

craterbot · 2025-07-18T18:14:30Z

🚨 Error: missing start toolchain

🆘 If you have any trouble with Crater please ask in t-infra on Zulip
ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

estebank · 2025-07-18T18:15:13Z

@bors try

Change the desugaring of `assert!` for better error output In the desugaring of `assert!`, we now expand to a `match` expression instead of `if !cond {..}`. The span of incorrect conditions will point only at the expression, and not the whole `assert!` invocation. ``` error[E0308]: mismatched types --> $DIR/issue-14091.rs:2:13 | LL | assert!(1,1); | ^ expected `bool`, found integer ``` We no longer mention the expression needing to implement the `Not` trait. ``` error[E0308]: mismatched types --> $DIR/issue-14091-2.rs:15:13 | LL | assert!(x, x); | ^ expected `bool`, found `BytePos` ``` Now `assert!(val)` desugars to: ```rust match val { true => {}, _ => $crate::panic::panic_2021!(), } ``` Fix #122159.

bors · 2025-07-18T18:16:25Z

⌛ Trying commit b3ffb52 with merge a2a6e87...

bors · 2025-07-18T20:30:11Z

☀️ Try build successful - checks-actions
Build commit: a2a6e87 (a2a6e871b05c7b8ecc9a3c8a20db1f39e995e399)

estebank · 2025-07-20T02:51:56Z

@craterbot check

craterbot · 2025-07-20T02:52:16Z

👌 Experiment pr-122661 created and queued.
🤖 Automatically detected try build a2a6e87
🔍 You can check out the queue and this experiment's details.

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

craterbot · 2025-07-23T15:41:32Z

🚧 Experiment pr-122661 is now running

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

craterbot · 2025-07-24T17:36:49Z

🎉 Experiment pr-122661 is completed!
📊 32 regressed and 10 fixed (668001 total)
📰 Open the summary report.

⚠️ If you notice any spurious failure please add them to the denylist!
ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

traviscross · 2025-07-24T22:33:25Z

It's interesting how this ends up interacting, on older editions, with things we improved in Rust 2024. Most (but not all) of the regressions match this pattern:

use core::cell::RefCell;

fn f1() {
    let x = RefCell::new([0u8]);
    if !x.borrow().is_empty() { //~ OK
        panic!()
    }
}

fn f2() {
    let x = RefCell::new([0u8]);
    match x.borrow().is_empty() {
        //[2021]~^ ERROR does not live long enough
        //[2024]~^ OK
        false => panic!(),
        _ => (),
    }
}

Both versions work in Rust 2024, but the latter fails in earlier editions due to the rule about temporaries in tail expressions. The f1 version works because if drops the temporaries in its condition before entering either branch, but match doesn't do this for its scrutinee, so the scopes of these temporaries extend beyond the match itself and therefore interact with the old-edition tail expression rule.

estebank · 2025-07-24T22:58:49Z

There are at least two potential sources of regressions:

Lifetimes:

[INFO] [stdout] error[E0597]: `data` does not live long enough
[INFO] [stdout]    --> src/controllers/servitor/authorization.rs:134:11
[INFO] [stdout]     |
[INFO] [stdout] 124 |         let data = mock_data(None);
[INFO] [stdout]     |             ---- binding `data` declared here
[INFO] [stdout] ...
[INFO] [stdout] 134 |         assert!(data.read().await.servitor.is_empty())
[INFO] [stdout]     |                 ^^^^-------------
[INFO] [stdout]     |                 |
[INFO] [stdout]     |                 borrowed value does not live long enough
[INFO] [stdout]     |                 a temporary with access to the borrow is created here ...
[INFO] [stdout] 135 |     }
[INFO] [stdout]     |     -
[INFO] [stdout]     |     |
[INFO] [stdout]     |     `data` dropped here while still borrowed
[INFO] [stdout]     |     ... and the borrow might be used here, when that temporary is dropped and runs the `Drop` code for type `tokio::sync::RwLockReadGuard`
[INFO] [stdout]     |
[INFO] [stdout] help: consider adding semicolon after the expression so its temporaries are dropped sooner, before the local variables declared by the block are dropped
[INFO] [stdout]     |
[INFO] [stdout] 134 |         assert!(data.read().await.servitor.is_empty());
[INFO] [stdout]     |                                                       +

I think I just need to change the desugaring to be for a statement of a match instead of a match expression.

Inference:

[INFO] [stdout] error[E0282]: type annotations needed
[INFO] [stdout]   --> java_runtime/tests/classes/java/util/jar/test_jar_file.rs:63:18
[INFO] [stdout]    |
[INFO] [stdout] 63 |     assert!(!jvm.invoke_virtual(&entries, "hasMoreElements", "()Z", ()).await?);
[INFO] [stdout]    |                  ^^^^^^^^^^^^^^ cannot infer type of the type parameter `U` declared on the method `invoke_virtual`
[INFO] [stdout]    |
[INFO] [stdout] help: consider specifying the generic arguments
[INFO] [stdout]    |
[INFO] [stdout] 63 |     assert!(!jvm.invoke_virtual::<(), U>(&entries, "hasMoreElements", "()Z", ()).await?);
[INFO] [stdout]    |                                +++++++++

I don't think there's anything we can do to avoid the inference regression, but thankfully only two crates have real code that triggers it.

teor2345 · 2025-07-24T23:16:50Z

Most fixes are spurious, they seem to be in build tools.

There are a few (expected?) type ambiguity errors, and many more drop order errors.

Type ambiguity (2 crates)

cradle 0.2.2

[INFO] [stdout] error[E0282]: type annotations needed
[INFO] [stdout]    --> src/lib.rs:972:21
[INFO] [stdout]     |
[INFO] [stdout] 972 |             assert!(!run_output!("false"));
[INFO] [stdout]     |                     ^^^^^^^^^^^^^^^^^^^^^ cannot infer type

dlunch/jvm -> rust_java v0.0.1 (?)

[INFO] [stderr]     Checking rust_java v0.0.1 (/opt/rustwide/workdir)
[INFO] [stdout] error[E0282]: type annotations needed
[INFO] [stdout]   --> java_runtime/tests/classes/java/util/jar/test_jar_file.rs:63:18
[INFO] [stdout]    |
[INFO] [stdout] 63 |     assert!(!jvm.invoke_virtual(&entries, "hasMoreElements", "()Z", ()).await?);
[INFO] [stdout]    |                  ^^^^^^^^^^^^^^ cannot infer type of the type parameter `U` declared on the method `invoke_virtual`
[INFO] [stdout]    |
[INFO] [stdout] help: consider specifying the generic arguments
[INFO] [stdout]    |
[INFO] [stdout] 63 |     assert!(!jvm.invoke_virtual::<(), U>(&entries, "hasMoreElements", "()Z", ()).await?);
[INFO] [stdout]    |                                +++++++++

Drop order (22 crates)

Most failures seem to be around drop order when the assert is not followed by a semicolon. Hyrum's law in action.

mutex lock drop order

syndicus 0.3.1

[INFO] [stderr]     Checking syndicus v0.3.1 (/opt/rustwide/workdir)
[INFO] [stdout] error[E0597]: `counter` does not live long enough
[INFO] [stdout]   --> src/scope.rs:79:18
[INFO] [stdout]    |
[INFO] [stdout] 65 |         let counter = scope::<_, ()>(|tasker| {
[INFO] [stdout]    |             ------- binding `counter` declared here
[INFO] [stdout] ...
[INFO] [stdout] 79 |         assert!(*counter.lock().await == task_load)
[INFO] [stdout]    |                  ^^^^^^^-------------
[INFO] [stdout]    |                  |
[INFO] [stdout]    |                  borrowed value does not live long enough
[INFO] [stdout]    |                  a temporary with access to the borrow is created here ...
[INFO] [stdout] 80 |     }
[INFO] [stdout]    |     -
[INFO] [stdout]    |     |
[INFO] [stdout]    |     `counter` dropped here while still borrowed
[INFO] [stdout]    |     ... and the borrow might be used here, when that temporary is dropped and runs the `Drop` code for type `tokio::sync::MutexGuard`
[INFO] [stdout]    |
[INFO] [stdout] help: consider adding semicolon after the expression so its temporaries are dropped sooner, before the local variables declared by the block are dropped
[INFO] [stdout]    |
[INFO] [stdout] 79 |         assert!(*counter.lock().await == task_load);

statsig-rust 0.6.2-beta.2507190239 in tests

Similar to the lock above:

[INFO] [stderr]     Checking statsig-rust v0.6.2-beta.2507190239 (/opt/rustwide/workdir)
…
[INFO] [stdout] error[E0597]: `obs_client` does not live long enough
[INFO] [stdout]    --> tests/event_logger_flush_tests.rs:346:13
…
[INFO] [stdout] 346 |     assert!(obs_client.error_calls.lock().unwrap().is_empty())

saptest 0.5.0 in tests

Similar to the lock above:

[INFO] [stderr]     Checking saptest v0.5.0 (/opt/rustwide/workdir)
[INFO] [stdout]    --> src/lib/tests/test_hard_mode_toy_t1.rs:164:13
…
[INFO] [stdout] error[E0597]: `pets` does not live long enough
[INFO] [stdout] 164 |     assert!(pets[2].read().unwrap().item.is_none())
…
[INFO] [stdout] error[E0597]: `pets` does not live long enough
[INFO] [stdout]    --> src/lib/tests/test_hard_mode_toy_t1.rs:192:13
[INFO] [stdout]     |
…
[INFO] [stdout] 192 |     assert!(pets[2].read().unwrap().item.is_none())

Also:

reqwest-conditional-middleware 0.4.0 in tests:
- src/lib.rs:161
- src/lib.rs:180
happylock 0.5.0 in tests (?)
- src/collection/boxed.rs, many errors
rainshowerLabs/blutgang
Angelin01/gjallarbot

Other drop order

scylla-cql 1.3.0 -> criterion v0.6.0 (?)

Iterator drop order

[INFO] [stderr]     Checking criterion v0.6.0
[INFO] [stdout] error[E0597]: `values` does not live long enough
[INFO] [stdout]    --> src/serialize/row_tests.rs:564:13
[INFO] [stdout]     |
[INFO] [stdout] 551 |       let mut values = SerializedValues::new();
[INFO] [stdout]     |           ---------- binding `values` declared here
[INFO] [stdout] ...
[INFO] [stdout] 564 |       assert!(values
[INFO] [stdout]     |               -^^^^^
[INFO] [stdout]     |               |
[INFO] [stdout]     |  _____________borrowed value does not live long enough
[INFO] [stdout]     | |
[INFO] [stdout] 565 | |         .iter()
[INFO] [stdout]     | |_______________- a temporary with access to the borrow is created here ...
[INFO] [stdout] 566 |           .all(|v| v == RawValue::Value(&[0, 0, 0, 0, 0x07, 0x5b, 0xcd, 0x15])))
[INFO] [stdout] 567 |   }
[INFO] [stdout]     |   -
[INFO] [stdout]     |   |
[INFO] [stdout]     |   `values` dropped here while still borrowed
[INFO] [stdout]     |   ... and the borrow might be used here, when that temporary is dropped and runs the destructor for type `impl Iterator<Item = RawValue<'_>>`
[INFO] [stdout]     |
[INFO] [stdout] help: consider adding semicolon after the expression so its temporaries are dropped sooner, before the local variables declared by the block are dropped
[INFO] [stdout]     |
[INFO] [stdout] 566 |         .all(|v| v == RawValue::Value(&[0, 0, 0, 0, 0x07, 0x5b, 0xcd, 0x15])));
[INFO] [stdout]     |

Also:

orc 0.0.1 in tests: heap allocator (?) drop order
- src/lib.rs:268
laurel 0.7.2 -> toml v0.8.20: RefCell
- src/coalesce.rs:1863
anyflux 0.1.0: Rc
- src/context.rs:152
analyse-json 0.6.1, cbrown1234/analyse-json in tests (?): Rc
- src/json/ndjson.rs, many errors
mukuact/simCAN: RefCell
l0s/rlox: Rc
kimond/rust_cmustify: RefCell
hi-rustin/rq: Iterator
gpabois/jarnac: RefPage
dlunch/Renderer: Iterator
babarai45/crux_fram: Iterator
astahhu/calendar-join: impl Deref
JohnMitchell04/toy-langauge: Ref, Result<Module<'_>, _>
Barandis/rust-c64: Ref

In the desugaring of `assert!`, we now expand to a `match` expression instead of `if !cond {..}`. The span of incorrect conditions will point only at the expression, and not the whole `assert!` invocation. ``` error[E0308]: mismatched types --> $DIR/issue-14091.rs:2:13 | LL | assert!(1,1); | ^ expected `bool`, found integer ``` We no longer mention the expression needing to implement the `Not` trait. ``` error[E0308]: mismatched types --> $DIR/issue-14091-2.rs:15:13 | LL | assert!(x, x); | ^ expected `bool`, found `BytePos` ``` `assert!(val)` now desugars to: ```rust match val { true => {}, _ => $crate::panic::panic_2021!(), } ``` Fix rust-lang#122159. We make some minor changes to some diagnostics to avoid span overlap on type mismatch or inverted "expected"/"found" on type errors. We remove some unnecessary parens from core, alloc and miri.

rustbot · 2025-07-25T00:47:27Z

This PR modifies tests/ui/issues/. If this PR is adding new tests to tests/ui/issues/,
please refrain from doing so, and instead add it to more descriptive subdirectories.

rustbot · 2025-07-25T00:47:29Z

⚠️ Warning ⚠️

There are issue links (such as #123) in the commit messages of the following commits.
Please move them to the PR description, to avoid spamming the issues with references to the commit, and so this bot can automatically canonicalize them to avoid issues with subtree.
- 9120542

estebank · 2025-07-25T00:49:06Z

@bors try

rust-bors · 2025-07-25T00:49:10Z

⌛ Trying commit 9120542 with merge b047d5f…

To cancel the try build, run the command @bors try cancel.

Change the desugaring of `assert!` for better error output

traviscross · 2025-07-25T02:43:02Z

If someone has a minimization of those type inference regressions, probably we'll be interested to look at that.

rust-bors · 2025-07-25T03:05:14Z

☀️ Try build successful (CI)
Build commit: b047d5f (b047d5f4496a7526d91d0dddea494c05853f2a7b, parent: b56aaec52bc0fa35591a872fb4aac81f606e265c)

estebank · 2025-07-25T03:52:26Z

@craterbot check

craterbot · 2025-07-25T03:52:50Z

👌 Experiment pr-122661-1 created and queued.
🤖 Automatically detected try build b047d5f
🔍 You can check out the queue and this experiment's details.

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

estebank · 2025-07-25T15:57:59Z

@traviscross I've been trying to replicate a case where inference fails under the new desugaring but the old doesn't, and I'm having trouble doing so.

rustbot assigned pnkfelix Mar 17, 2024

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Mar 17, 2024

estebank commented Mar 17, 2024

View reviewed changes

This comment has been minimized.

Sign in to view

estebank force-pushed the assert-macro-span branch from ead1593 to eb411c1 Compare March 17, 2024 21:27

This comment has been minimized.

Sign in to view

This comment was marked as resolved.

Sign in to view

This comment has been minimized.

Sign in to view

pnkfelix mentioned this pull request Mar 18, 2024

inconsistent and confusing error message about first argument of assert! #122159

Open

rustbot added the I-lang-nominated Nominated for discussion during a lang team meeting. label Mar 18, 2024

Veykril reviewed Mar 18, 2024

View reviewed changes

src/tools/rust-analyzer/crates/parser/test_data/parser/ok/0035_weird_exprs.rs Outdated Show resolved Hide resolved

estebank force-pushed the assert-macro-span branch from c8185ea to 07a5b21 Compare March 18, 2024 23:59

This comment has been minimized.

Sign in to view

craterbot added S-waiting-on-crater Status: Waiting on a crater run to be completed. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jul 20, 2025

craterbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-crater Status: Waiting on a crater run to be completed. labels Jul 24, 2025

estebank force-pushed the assert-macro-span branch from b3ffb52 to 9120542 Compare July 25, 2025 00:47

rust-bors bot added a commit that referenced this pull request Jul 25, 2025

Auto merge of #122661 - estebank:assert-macro-span, r=<try>

b047d5f

Change the desugaring of `assert!` for better error output

craterbot added S-waiting-on-crater Status: Waiting on a crater run to be completed. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jul 25, 2025

Change the desugaring of assert! for better error output #122661

Are you sure you want to change the base?

Change the desugaring of assert! for better error output #122661

Conversation

estebank commented Mar 17, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rustbot commented Mar 17, 2024

Uh oh!

rustbot commented Mar 17, 2024

Uh oh!

estebank Mar 17, 2024

Choose a reason for hiding this comment

Uh oh!

estebank Mar 17, 2024

Choose a reason for hiding this comment

Uh oh!

This comment has been minimized.

This comment has been minimized.

estebank commented Mar 17, 2024

Uh oh!

This comment was marked as resolved.

This comment has been minimized.

pnkfelix commented Mar 18, 2024

Uh oh!

pnkfelix commented Mar 18, 2024

Uh oh!

Uh oh!

estebank commented Mar 18, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

pnkfelix commented Mar 18, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

pnkfelix commented Mar 18, 2024

Uh oh!

rustbot commented Mar 19, 2024

Uh oh!

estebank commented Mar 19, 2024

Uh oh!

This comment has been minimized.

compiler-errors commented Mar 19, 2024

Uh oh!

estebank commented Mar 19, 2024

Uh oh!

pnkfelix commented Mar 20, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

pnkfelix commented Mar 22, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

craterbot commented Jul 18, 2025

Uh oh!

estebank commented Jul 18, 2025

Uh oh!

bors commented Jul 18, 2025

Uh oh!

bors commented Jul 18, 2025

Uh oh!

estebank commented Jul 20, 2025

Uh oh!

craterbot commented Jul 20, 2025

Uh oh!

craterbot commented Jul 23, 2025

Uh oh!

craterbot commented Jul 24, 2025

Uh oh!

traviscross commented Jul 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

estebank commented Jul 24, 2025

Uh oh!

teor2345 commented Jul 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Type ambiguity (2 crates)

Drop order (22 crates)

mutex lock drop order

Other drop order

Uh oh!

rustbot commented Jul 25, 2025

Change the desugaring of `assert!` for better error output #122661

Change the desugaring of `assert!` for better error output #122661

estebank commented Mar 17, 2024 •

edited

Loading

estebank commented Mar 18, 2024 •

edited

Loading

pnkfelix commented Mar 18, 2024 •

edited

Loading

pnkfelix commented Mar 20, 2024 •

edited

Loading

pnkfelix commented Mar 22, 2024 •

edited

Loading

traviscross commented Jul 24, 2025 •

edited

Loading

teor2345 commented Jul 24, 2025 •

edited

Loading